home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1996 #15 / Monster Media Number 15 (Monster Media)(July 1996).ISO / netmail / netg4p.zip / WHATSNEW.100 < prev   
Text File  |  1996-05-26  |  31KB  |  919 lines

  1. gamma 4
  2. -------
  3.  
  4. * The AKAFORCE statement in netmgr.cfg was broken (didn't work at all).
  5.   Problem reported by Francois Blais.
  6.  
  7. * Searching for a string (not a substring with ~) in the subject line
  8.   in an Xmask would not always work correctly.
  9.   Problem reported by Peter Karlsson.
  10.  
  11. * NetMgr's config file wasn't opened in a file sharing mode.
  12.   Problem reported by Vicki Fletcher.
  13.  
  14. * The 'PackMail' action would replace the 'subject' line in file request
  15.   messages with the name(s) of the requested file(s), even for JAM messages
  16.   with a 'real' subject line.
  17.   Problem reported by Francois Blais.
  18.  
  19. * For messages with file attaches or requests, the 'subject' line would
  20.   sometimes be empty for bounce messages. This is now fixed.
  21.   Problem reported by Pepijn Hendriks.
  22.  
  23.  
  24. beta 8
  25. ------
  26.  
  27. * There were two clashes with tokens used to represent attributes.
  28.   The JAM zonegating bit is now : %
  29.   The locked status is now      : $
  30.  
  31. * The variables (like %from, %to and so on) can also used in files used for
  32.   the 'AddNote' action.
  33.  
  34. * Productcode in mailpackets now set to 0xFE instead of 0x00
  35.  
  36. * The -q command line switch produced junk in the logfile.
  37.  
  38. * NetMgr would open _every_ area as a netmail area, which is not correct
  39.   when doing an EchoCopy/Move. Mails created with EchoCopy/Move could
  40.   therfore give trouble.
  41.  
  42. * When using the -@ or -# pseudo attributes, the debug output would show
  43.   incorrect information.
  44.  
  45. * Doing a copy/move on messages without any kludges resulted in a
  46.   protection violation.
  47.  
  48. * MoveMail lost names of attaches/requests from the subject line.
  49.  
  50. * Action FILE in the DOS version gave problems, that could range from not
  51.   writing the output correctly to crashing the computer.
  52.  
  53. * You can now use the variables (%from, %to etc) in Action Display. This
  54.   also fixes a problem that gamma 2 had when you specified % tokens in a
  55.   display action.
  56.  
  57. * When scanning for a certain keyword on the subject line, it was not
  58.   possible to scan for filename for attaches and requests. In areas other
  59.   than JAM, this information is actually stored in the subject line, so
  60.   scanning should be possible (but it didn't work because NetMgr stores
  61.   this information separately).
  62.  
  63.   NetMgr will now also scan the list of attached/requested files when
  64.   looking for a certain string in the subject.
  65.   So doing this...
  66.  
  67.   Mask Allfix, *, *, *, ~TIC, +a
  68.   Action Delete
  69.  
  70.   .. should now do what it's told (delete file attach messages that come
  71.   from allfix and show the word 'TIC" in the subject, or in other words:
  72.   that have a TIC file attachd).
  73.  
  74.  
  75. * Some other cosmetical things.
  76.  
  77.  
  78. beta 7
  79. ------
  80.  
  81. * Don't remember what happened here :-)
  82.  
  83.  
  84. beta 6
  85. ------
  86.  
  87. * The 'dest' keyword in XMASKs didn't work (at all).
  88.  
  89. * NetMgr stripped the already existing trailing VIA lines when packing mail
  90.   (it just added it's own :-)
  91.  
  92. * NetMgr now also allows the OR construction for attributes. So something
  93.   like this is now also possible:
  94.  
  95.   XMASK
  96.       From Gerard van Essen
  97.       Orig 2:281/527.0
  98.       Attr +c OR +a+l OR +f-c
  99.   END
  100.  
  101.   This mask will match for messages that are flavoured crash, or are
  102.   flavoured 'attach' and 'local', or flavoured 'request' but NOT crash.
  103.  
  104.   Please note that this construction is not valid for the attributes that
  105.   need to search the nodelist (# and @). You can specify these attributes
  106.   like this, but they are checked once, separately from the other
  107.   attributes.
  108.   So you cannot specify:
  109.  
  110.   Attr +c-@ OR -c+@
  111.  
  112.   or something similar. You can only specify these attributes once and they
  113.   will then be carried over to all other attribute masks. In other words,
  114.   specifying this:
  115.  
  116.   Attr +c-@ OR +l
  117.  
  118.   will actually be expanded to:
  119.  
  120.   Attr +c-@ OR +l-@
  121.  
  122.  
  123. beta 5
  124. ------
  125.  
  126. * Added the ability to run external programs from NetMgr.
  127.  
  128.   The action to use for this is RUNEXTERNAL.
  129.   Format:
  130.  
  131.   RUNEXTERNAL <program to use> <parameters>.
  132.  
  133.   In the <paramaters> part, you can make use of several 'variables', whose
  134.   value depends on the contents of the header of the message that triggered
  135.   the action. The following variables are available:
  136.  
  137.   from       - Name in the 'from' field of current message.
  138.   to         -             'to'
  139.   subject    -             'subject'
  140.   orig       - Origination address of current message (like 2:281/527).
  141.   dest       - Destination address of current message (like 2:281/527).
  142.   areadir    - Directory or base name of current area, board number if
  143.                Hudson. This is in the format that is also used in
  144.                NetMgr.cfg, so $<path+basename> for a Squish area,
  145.                !<path+basename> for a JAM area etc.
  146.   msgno      - Message number of current message ('relative' number for
  147.                Squish and Hudson)
  148.   realmsgno  - Real message number, for Squish (UMSGID) and Hudson (real
  149.                number in Hudson base, not the relative number in the area).
  150.                For JAM and *.MSG, this is always equal to msgno.
  151.   file       - Name of the file that contains the body of the message.
  152.   newfile    - Name of a new file to create if you want to replace the body
  153.                of the message with new text.
  154.   repfile    - Name of the file that should be created if you want to send
  155.                a message back to the sender of the message. (See below).
  156.   attach     - Files attached to this message (list of files).
  157.   request    - Files requested in this message (list of files [!passwords]).
  158.  
  159.   (But then on one line, evidently).
  160.  
  161.   Before running the external program, NetMgr will write the body of the
  162.   message to a file. This file (and other files) will be created in the
  163.   directory where NetMgr found it's config file. The path+name of this file
  164.   is available through the variable [file]. It will be:
  165.   "<path to config file>\netmsg.msg".
  166.  
  167.   NetMgr will then run the external program, and check for the existence of
  168.   two files:
  169.  
  170.   ■  "<path to config file>\netmsg.new" : if this file exists, NetMgr will
  171.      replace the body of the message with the contents of this file. The
  172.      path+name of this variable is available through the variable
  173.      [newfile].
  174.  
  175.   ■  "<path to config file>\netmsg.rep": if this file exists, NetMgr will
  176.      send a message back to the sender of the message that triggered this
  177.      action.
  178.      What is actually done, is an XEMPTYBOUNCE action. For this action, the
  179.      netmsg.rep file is used as the body (where the variables like [from],
  180.      [to] etc. can be used), but where the first line of this .rep file is
  181.      used as the 'mask' for the reply header.
  182.      Because it actually _is_ an XEMPTYBOUNCE, it also follows the same
  183.      conventions as the XEMPTYBOUNCE action, so it initializes the fields
  184.      with a standard reply header, which makes it possible to use a simple
  185.      '*, *, *, *, *, *' mask (see XEMPTYBOUNCE action for more info).
  186.      The path+name of this variable is available through the variable
  187.      [repfile].
  188.  
  189.   An example:
  190.  
  191.   Action RUNEXTERNAL pgp.exe +batchmode -sta -u art -o [newfile] -z pass [file]
  192.  
  193.   could expand to:
  194.  
  195.   'pgp.exe +batchmode -sta -u art -o c:\net\netmsg.new -z pass
  196.                                                             c:\netmgr\net.msg'
  197.  
  198.   This would run PGP on the message, and sign the text. The body of the
  199.   message will be replaced with a signed version of the text.
  200.  
  201.   An example of usage of a .rep file could be:
  202.  
  203.   Action RUNEXTERNAL reply.cmd [repfile]
  204.  
  205.   And the contents of 'reply.cmd' could be:
  206.  
  207.   @echo off
  208.   echo Automatic Reply, @myaka, *, *, Response to your message, * >> %1
  209.   echo Hello %%ffrom! >> %1
  210.   echo. >> %1
  211.   echo This is an automatic reply! >> %1
  212.   echo. >> %1
  213.   echo Greetings! >> %1
  214.  
  215.   This would create a netmsg.rep file, and NetMgr would send back a small
  216.   message to the sender of the original message.
  217.  
  218.  
  219. * Several actions have a similar counterpart, that can place the resulting
  220.   message in another area.
  221.   The actions concerned are: the Bounce and XBounce 'family', Forward and
  222.   MakeMsg. In order to place the resulting message in another area, add
  223.   'IN' to the action name (to make BOUNCEIN, XBOUNCEIN, XEMPTYBOUNCEIN,
  224.   FORWARDIN etc), and add the path/name of the area to put the message in.
  225.  
  226.   Some examples:
  227.  
  228.   Action XBOUNCEIN $d:\msg\net bounce.txt The Bouncer, @myaka, *, *, *, +l
  229.  
  230.   This will create a bounce message in the Squish area d:\msg\net.
  231.  
  232.   Action FORWARDIN !c:\msgbase\netmail *, *, Pietje Puk, 2:2/2.0, *, +l
  233.  
  234.   This will forward a message to 'Pietje Puk (2:2/0)' in the JAM style area
  235.   c:\msgbase\netmail.
  236.  
  237.  
  238.  
  239. beta 4
  240. ------
  241.  
  242. * When deleting messages in *.MSG areas, NetMgr will attempt to correct the
  243.   lastread pointer so that it keeps pointing to an existing ('old')
  244.   message.
  245.  
  246.  
  247. * For *.MSG areas, you can now specify the optional 'renum' keyword when
  248.   you define the area using the 'ScanDir' keyword.. After scanning the
  249.   area, NetMgr will then renumber the area (and adjust the lastread pointer
  250.   when necessary).
  251.  
  252.   Example of such a definition:
  253.  
  254.   ScanDir c:\fd\netmail renum
  255.  
  256.  
  257. * TimEd will now by default add an INTL kludge to all newly generated
  258.   netmail (bounce, makemsg).
  259.  
  260.  
  261. * With the action 'FILE', NetMgr would 'eat' characters if a certain line
  262.   was longer than 79 characters and didn't contain any spaces. This is now
  263.   fixed.
  264.  
  265.  
  266. * New keyword: INTLFORCE
  267.   If you add this to your NetMgr.cfg, timEd will _force_ an INTL kludge on
  268.   any netmail it somehow writes (this includes messages touched through a
  269.   REWRITE, COPY/MOVE etc).
  270.  
  271.  
  272. * Fixed a problem for UUCPREWRITE on messages generated by Maximus (which
  273.   have a trailing ^A in their kludges).
  274.  
  275.  
  276. * For the Actions 'Forward' and 'MakeMsg' the header (that is: from, to,
  277.   subject, destination address, origination address and attributes) will
  278.   be initialized with the contents of the original message.
  279.  
  280.   Putting a '*' in fields of the Masks for the Forward and MakeMsg actions
  281.   will, as a result, produce the contents of the original message.
  282.  
  283.   An example:
  284.  
  285.   Action Forward *, *, Kasper Kwant, 2:500/144.0, *, +l+c
  286.  
  287.   A message like this:
  288.  
  289.   From: Gerard, 2:281/527
  290.   To  : SysOp,  1:138/211
  291.   Subj: Test!
  292.   Attr: -
  293.   ----------------------------------
  294.  
  295.   Will produce a message like this:
  296.  
  297.  
  298.   From: Gerard, 2:281/527
  299.   To  : Kasper Kwant, 2:500/144
  300.   Subj: Test!
  301.   Attr: Loc, Cra
  302.   ----------------------------------
  303.   * Forwarded by NetMgr+ 1.00.g2
  304.  
  305.   Original message:
  306.   From:
  307.   To  :           <--- header of original message.
  308.   Subj:
  309.   ----------------
  310.   Bla, bla        <--- body of original message.
  311.  
  312.  
  313. * {+} The BOUNCE, HDRBOUNCE and EMPTYBOUNCE Actions have 'extended'
  314.   counterparts: XBOUNCE, XHDRBOUNCE and XEMPTYBOUNCE.
  315.  
  316.   The format:
  317.   XBOUNCE <textfile for bouncetext> <full mask to use>
  318.  
  319.   The first parameter is the textfile to add at the top of the bounce
  320.   message.
  321.   The second parameter is the mask to use for the bounce message. You can
  322.   specify a "*" for the fields you want the default to be used.
  323.  
  324.   By default, NetMgr generates a full 'reply header' with the to: and from:
  325.   names and addresses reversed (compared to the original message) and the
  326.   same attributes and subject.
  327.  
  328.   For example, for this message:
  329.  
  330.   From: Gerard, 1:1/1
  331.   To  : SysOp,  1:138/211
  332.   Subj: Test!
  333.   Attr: Pvt Cra
  334.   ----------------------------------
  335.  
  336.   The standard reply header is:
  337.  
  338.   From: SysOp,  1:138/211
  339.   To  : Gerard, 1:1/1
  340.   Subj: Test!
  341.   Attr: Pvt Cra
  342.   ----------------------------------
  343.  
  344.   And that will be the result if you specify a mask like:
  345.  
  346.   Action XBounce c:\txt\bounce.txt *, *, *, *, *, *
  347.  
  348.   However, if you make it:
  349.  
  350.   Action XBounce c:\txt\bounce.txt The Bodyguard, 2:281/527.0, *, *, *, +l
  351.  
  352.   The result would be:
  353.  
  354.   From: The Bodyguard,  2:281/527
  355.   To  : Gerard,         1:1/1
  356.   Subj: Test!
  357.   Attr: Loc
  358.   ----------------------------------
  359.  
  360.   The extended bounce actions are only available to registered users.
  361.  
  362.  
  363. * {+} The BOUNCE and XBOUNCE actions can now use variables in the textfiles
  364.   that can be inserted at the top of the message.
  365.  
  366.   For a BOUNCE action like...
  367.  
  368.   Action Bounce 2:281/527.0 c:\txt\bounce.txt
  369.  
  370.   .. this is the file c:\txt\bounce.txt.
  371.  
  372.   These variables will be expanded using the contents of the message-header
  373.   of the message you are bouncing. This gives you the opportunity to make
  374.   the messages a bit more 'personal'.
  375.  
  376.   In the file, the use of the following variables is now allowed:
  377.  
  378.   %to    :    The full name of the person that the the original message was
  379.               addressed to.
  380.  
  381.   %fto   :    As %to, but only the first name of that person.
  382.  
  383.   %from  :    The full name of the person who wrote the original message.
  384.  
  385.   %ffrom :    As %from, but only the first name of that person.
  386.  
  387.   %subj  :    Subject of the original message.
  388.  
  389.   %orig  :    Address of the sender of the message (like
  390.               2:281/527)
  391.  
  392.   %dest  :    Address of the recipient of the message
  393.               (like 2:281/527)
  394.  
  395.   %time  :    Time the message was written (like 01:25)
  396.   %year  :    The year the message was written (like 1993)
  397.   %mon   :    The month the message was written (like jan,
  398.               feb etc)
  399.   %day   :    The day of the month msg was written (a
  400.               number)
  401.   %dow   :    The 'day of week' msg was written (like mon,
  402.               tue, wed etc)
  403.  
  404.   So, the contents of the bounce file could be:
  405.  
  406.   -=-
  407.  
  408.   Hello %ffrom!
  409.  
  410.   You sent a message to %to (%dest), dated %mon %day, %year.
  411.   The subject was: "%subj".
  412.  
  413.   -=-
  414.  
  415.   These variables can only be used by registered users of NetMgr.
  416.  
  417.  
  418. * PackMail and MoveMail will now add FMPT/TOPT kludges at the very start of
  419.   the kludges, instead of at the end. This seems to prevent problems at
  420.   Frodo systems that didn't correctly recognize file attaches addressed to
  421.   points in some cases.
  422.  
  423.  
  424. * New Action: DeleteAttach
  425.  
  426.   This action will not only delete the message, but it will also look at
  427.   any attached files. When the 'Truncate when sent' flag is present on the
  428.   message, the file(s) will be truncated. When the 'Kill file when sent'
  429.   flag is present, the attached file(s) will be deleted.
  430.  
  431.  
  432. * New Action: ChangePathMove <new path>
  433.  
  434.   This works exactly like 'ChangePath', but it also moves the attached
  435.   file(s) to the new directory.
  436.  
  437.  
  438. * Added the possibility to post files in a message from the command line.
  439.  
  440.   In order to do this, use the POST command on the commandline.
  441.  
  442.   To do a post, you first need to define an XMASK with DefineXMask in
  443.   NetMgr.cfg. In that mask, specify "from", "to", "subject", and "orig" for
  444.   echomail messages. For netmail messages, you need to add "dest" as well.
  445.   Adding 'attr' is allowed, but not required. If you don't specify any
  446.   attributes, NetMgr will default to (only) the 'local' attribute.
  447.  
  448.   When generating the message, NetMgr will use the info in this XMASK to
  449.   generate the header for the message.
  450.  
  451.   On the command line, you specify which xmask to use, what file to use as
  452.   body, the area to post in, and whether or not the area is an echomail
  453.   area. To do this, the following command line options are available:
  454.  
  455.   -x : specify XMASK to use
  456.   -a : specify area to use (use leading !, # or $ to indicate msgbase format)
  457.   -e : specified area is an echomail area
  458.   -f : ASCII file to use as body for the message
  459.  
  460.   Full example:
  461.  
  462.   Provided the following XMASK is defined in NetMgr.cfg:
  463.  
  464.   DefineXmask netpost
  465.  
  466.      from    Gerard van Essen
  467.      to      NetMgr User
  468.      subject Answer to your query
  469.      orig    2:281/527.0
  470.      dest    2:2/0.0
  471.  
  472.   End
  473.  
  474.   The following command line...
  475.  
  476.   NetMgr POST -xnetpost -a$c:\fd\netmail -fc:\txt\canned.rep
  477.  
  478.   ... would generate a new netmail message in the Squish style area
  479.   'c:\fd\netmail', with the header specified (i.e.: to 'NetMgr User', from
  480.   'Gerard van Essen' etc), and with the textfile 'c:\txt\canned.rep' as
  481.   the body.
  482.  
  483.   NetMgr will start up, read the config, open the area, post the message,
  484.   and then exit immediately (without scanning the netmail area as is
  485.   normally done).
  486.  
  487.  
  488.   Provided the following XMASK is defined in NetMgr.cfg:
  489.  
  490.   DefineXmask rules
  491.  
  492.      from    Moderator
  493.      to      All
  494.      subject The monthly rules
  495.      orig    2:281/527.0
  496.  
  497.   End
  498.  
  499.   The following command line...
  500.  
  501.   NetMgr POST -xrules -a!c:\echo\artware -fc:\txt\artware.rul -e
  502.  
  503.   ... would generate a new echomail message in the JAM style area
  504.   'c:\echo\artware', with the header specified (i.e.: to 'All', from
  505.   'Moderator' etc), and with the textfile 'c:\txt\artware.rul' as the body.
  506.  
  507.  
  508. * Added some outbound management capabilities, usable from the command
  509.   line. You can use one of the following commands on the command line:
  510.  
  511.   ■ POLL   : create a poll packet for a certain node.
  512.   ■ GET    : create a filerequest for a certain node.
  513.   ■ UPDATE : create an update request for a certain node.
  514.   ■ SEND   : create a file attach for a certain node.
  515.   ■ CHANGE : change mail status for mail waiting for a certain node.
  516.  
  517.   To support this, the following command line options are used:
  518.  
  519.   -s  : Status (also called 'flavour') of request/attach.
  520.   -n  : New status for mail (used for 'CHANGE').
  521.   -p  : Password to use for file request.
  522.   -#  : Node address of node to request files from / send files to.
  523.   -f  : File to send/request.
  524.  
  525.   The 'POLL'   command needs: -# and -s.
  526.   The 'GET'    command needs: -#, -f and -s (optional: -p).
  527.   The 'UPDATE' command needs: -#, -f and -s (optional: -p).
  528.   The 'SEND'   command needs: -#, -f and -s.
  529.   The 'CHANGE' command needs: -#, -s and -n.
  530.  
  531.   For the '-s' and '-n' options, the following flavours can be used:
  532.   normal, crash, imm, hold, dir.
  533.  
  534.   Examples:
  535.  
  536.   NetMgr POLL -#2:281/527 -scrash
  537.  
  538.   Poll node 2:281/527, crash status.
  539.  
  540.  
  541.   NetMgr GET -#2:500/133 -fnewfiles -shold -psecret
  542.  
  543.   Request from node 2:500/133, with 'hold' status, the file 'NEWFILES' and
  544.   use 'secret' as password for this request.
  545.  
  546.  
  547.   NetMgr SEND -fc:\autoexec.bat -simm -#1:138/211
  548.  
  549.   Attach the file c:\autoexec.bat, with 'immediate' status, to 1:138/211.
  550.  
  551.  
  552.   NetMgr CHANGE -snormal -ncrash -#2:281/527.5
  553.  
  554.   Change the flavour of all mail destined for 2:281/527.5 flavoured
  555.   'normal' to a new flavour of 'crash'.
  556.  
  557.  
  558.   For any of the above to work, you need to have the 'OutBound' keyword
  559.   defined in NetMgr.cfg.
  560.  
  561.  
  562. * NetMgr now has AKAmatching capabilities, that can be used in several
  563.   places.
  564.  
  565.   In order to let NetMgr do this, add all the addresses you might want to
  566.   use to NetMgr.cfg (multiple 'homeaddress' statements are now allowed).
  567.   By default, NetMgr can do the matching for you without any further info.
  568.  
  569.   This option is interesting if you have more than 1 address.
  570.   NetMgr can then be ordered to find the most appropriate address to use
  571.   when writing a message.
  572.  
  573.   Say, for example, that you have two addresses: 2:281/527 and
  574.   60:100/112.
  575.  
  576.   If you write a messages to 2:500/133, you probably want to use
  577.   your 2:281/527 address.
  578.   If you write a message to 60:100/1, you probably want to use
  579.   your 60:100/112 address.
  580.  
  581.   In this case, NetMgr would try to find the address (AKA) that 'matches'
  582.   the destination address best.
  583.  
  584.   It first looks for a matching zone, and if more than one match
  585.   is found, it'll try to find an address where both 'zone' and
  586.   'net' match. If there is still more than one match after that,
  587.   it will just take the first match.
  588.  
  589.   If you want to make exceptions to these matching rules, or if you want to
  590.   do AKAmatching _within_ a certain net, you can force NetMgr to use
  591.   certain AKA by using the AKAFORCE keyword in NetMgr.cfg:
  592.  
  593.   Format:
  594.  
  595.   AKAFORCE <mask> <address to use>
  596.  
  597.   example:
  598.  
  599.   AKAFORCE 50:*/*.* 49:500/1
  600.  
  601.   This means: always use 49:500/1 as address when mail is sent to any zone
  602.   50 address. This forcing will take precedence over 'automatic'
  603.   akamatching.
  604.  
  605.   Where does it work?
  606.  
  607.   First of all, NetMgr can now pick the correct AKA to use when generating
  608.   a new message using one of the BOUNCE, XBOUNCE, MakeMsg or Forward
  609.   actions.
  610.  
  611.   In order to let NetMgr pick an appropriate address, use '@myaka' instead
  612.   of a 4D address. For example:
  613.  
  614.   Action Bounce @myaka c:\txt\bounce.txt
  615.  
  616.   Or:
  617.  
  618.   Action Xbounce c:\txt\bounce.txt The Bouncer, @myaka, *, *, Go away!, *
  619.  
  620.   You can also use the AKA matching with REWRITE. This is probably only
  621.   useful when you are currently using NetMgr already to do AKAmatching with
  622.   several masks. You may now be able to do it with one mask/action:
  623.  
  624.   Mask Gerard van Essen, *, *, *, *, +l
  625.   Action Rewrite *, @myaka, *, *, *, *
  626.  
  627.  
  628.   Finally, you can also use it for the PackMail and MoveMail actions, for
  629.   the origination address:
  630.  
  631.   Action PackMail @myaka *
  632.  
  633.   This will pack all mail directly to their destination, and use a matching
  634.   AKA in the packet header as origination address. Please note that this
  635.   (obviously!) does not have any effect on the addresses used within the
  636.   packed messages! Only the packet header is affected by this!
  637.  
  638.  
  639. beta 3
  640. ------
  641.  
  642. *  Switched to Watcom for the DOS version.
  643.  
  644. *  Switched to heavily modified message base code (as was also introduced
  645.    in timEd 1.10).
  646.  
  647. *  Added some new attributes to be used:
  648.  
  649.    2 = XX2 : officially unused/reserved
  650.    b = ARQ : is return receipt
  651.    g = CFM : confirm receipt request
  652.    h = LOK : message is locked
  653.    z = ZGT : JAM, zonegate bit
  654.    x = FAX : message is a FAX cover
  655.  
  656. *  Fixed trap that occurred when echocopying empty messages.
  657.  
  658. *  Immediate flavour (used by at least Xenia and McMail) is now supported
  659.    for Binkley style outbound mail packing.
  660.  
  661. *  For JAM areas, NetMgr can now write NETMAIL/ECHOMAIL.JAM. Add the
  662.    keyword 'JAMLOG' to NetMgr.cfg and give the directory to put the files
  663.    in.
  664.    Example:
  665.  
  666.    JamLog c:\fd\msgbase\
  667.  
  668.  
  669. *  Added eXtended Mask (XMASK) capabilities.
  670.  
  671.    XMASKs allow you to specify many more criteria than a standard mask.
  672.    However, they also take a bit more room than a standard mask. They can
  673.    be used together with standard masks (even mixed within the same config).
  674.  
  675.    To define an extended mask, use the XMASK keyword. An XMASK definition
  676.    always starts with this keyword, and always ends with a line with only
  677.    'End' on it. Between these two lines, search criteria are defined.
  678.  
  679.    An example:
  680.  
  681.    Xmask
  682.      from   Gerard van Essen
  683.    End
  684.  
  685.    This defines an XMASK, that looks for messages that are FROM: 'Gerard
  686.    van Essen'.
  687.  
  688.    You can specify more than one criterium. For a message to be a match, it
  689.    must satisfy _all_ requirements that are defined. So, if you have:
  690.  
  691.    Xmask
  692.      from   Gerard van Essen
  693.      to     pietje puk
  694.    End
  695.  
  696.    A message is only a match when it is from 'Gerard van Essen' _and_ to
  697.    'pietje puk'.
  698.  
  699.    The following keywords can be used in an XMASK:
  700.  
  701.    from      - who the message is from
  702.    to        - who the message is to
  703.    subject   - the subject of the message
  704.    attr      - attributes of a message (like +a-p etc, like a standard mask)
  705.    kludge    - a search text to be found in the kludges of a message
  706.    body      - a search text to be found in the body of a message
  707.  
  708.    bodybytes <n> - how many bytes of the message body must be searched to find
  709.                    the string(s) specified to find in the body.
  710.    bodylines <n> - how many lines of the body to search (or actually
  711.                    paragraphs, separated by a CR (ASCII 13, '\r').
  712.  
  713.    orig      - origination address of the message (like 2:281/527.0 - always 4D)
  714.    dest      - destination address of the message (like 2:281/527.0 - always 4D)
  715.  
  716.    olderwritten <n>   - 'Date written' of the message must be older than n days.
  717.    olderprocessed <n> - 'Date processed' of the message must be older than n
  718.                          days (JAM, Squish, SDM).
  719.    olderread <n>      - 'Date msg read by recipient' of the message must be
  720.                          older than n days (JAM only).
  721.  
  722.  
  723.    When searching for a string (from, to, subject, body, kludges), you can
  724.    also enclose a string in either single or double quotes. This gives you
  725.    the opportunity to search for trailing and/or leading spaces.
  726.  
  727.    Even when quotes are used, the ~ (substring) and ! (NOT search) tokens
  728.    are still supported, just like in normal MASKs. These tokens must be
  729.    entered inside the quote, so "~gerard" will look for the substring
  730.    'gerard' to be present anywhere.
  731.  
  732.    Specifying a certain keyword more than once, gives you an AND search. As
  733.    mentioned before, _all_ requirements that are defined must be met. So
  734.    specifying:
  735.  
  736.    Xmask
  737.      body "gerard"
  738.      body "timed"
  739.    End
  740.  
  741.    .. will look for messages that have 'gerard' AND 'timed' in the body.
  742.    However, you can also do an OR search, by specifying more than one
  743.    element on the same line, enclosed in quotes and separated by the OR
  744.    keyword, like this:
  745.  
  746.    Xmask
  747.      body "gerard" OR "timed"
  748.    End
  749.  
  750.    This will look for messages that have 'gerard' in the body, OR that have
  751.    'timed' in the body.
  752.  
  753.    You can also do a similar thing with addresses:
  754.  
  755.    Xmask
  756.      orig 2:*/*.* OR 1:*/*.*
  757.    End
  758.  
  759.    This will look for message originating from either zone 2 or zone 1.
  760.    You can also do an AND search with addresses:
  761.  
  762.    Xmask
  763.      orig 2:*/*.*
  764.      orig !2:281/527.*
  765.    End
  766.  
  767.    This will look for messages originating from zone 2, and NOT from node
  768.    2:281/527 or any of its points.
  769.  
  770.    Finally, for from, to, subject, kludges, body, orig and dest, you can
  771.    also specify a filename as input. The filename must be preceded by a
  772.    '<', like this:
  773.  
  774.    to  <c:\data\names.txt
  775.  
  776.    The file itself should consist of a number of lines, all with one
  777.    string/addrress to look for. If any of the strings/addresses are found,
  778.    this will be considered a match.
  779.    In the case of names.txt, the file could look like this:
  780.  
  781.    -=-
  782.    Areafix
  783.    Areamgr
  784.    SQafix
  785.    -=-
  786.  
  787.    Any message addressed to 'Areafix', OR 'Areamgr' OR 'SQafix' will be a
  788.    match.
  789.    Leading and trailing spaces on a line in the file will be stripped.
  790.    Quotes are not allowed. However, use of the '~' and '!' tokens _is_
  791.    allowed.
  792.  
  793.  
  794.    One or more XMASKs must be combined with one or more actions, just like
  795.    a standard MASK:
  796.  
  797.    XMASK
  798.      from  Gerard van Essen
  799.    End
  800.    Action Delete
  801.  
  802.  
  803.    You can also define an XMASK, give it a name, and use it later on in the
  804.    .cfg file. To define an XMASK, use the 'DefineXmask' keyword:
  805.  
  806.    DefineXmask <mask name>
  807.      ...
  808.      <mask criteria>
  809.      ...
  810.    End
  811.  
  812.    Like this:
  813.  
  814.    DefineXmask personal
  815.       to "Gerard van Essen" OR "gerard van.essen" OR "art" OR "Geer art"
  816.    End
  817.  
  818.    Later on, you can then use the XMASK named personal again:
  819.  
  820.    XMASK personal
  821.    Action Move $c:\mail\personal
  822.  
  823.    Pfffffffff....  I think this more or less explains the new XMASK
  824.    capabilities.
  825.  
  826.  
  827. beta 2
  828. ------
  829.  
  830. *  EchoCopy/Move now check for an already existing Origin/Tearline and
  831.    strip it off before adding a new and correct Origin line.
  832.  
  833. *  Using multiple actions for one Mask in Squish areas with a 'max msgs'
  834.    limit set could cause trouble. If the first action added a message to
  835.    the area ('bounce' for example), NetMgr would lose it's orientation (due
  836.    to the 'sliding' message numbers) and perform subsequent actions on the
  837.    wrong message. This was particularly good fun for 'Action Delete' and
  838.    similar..
  839.  
  840. *  The 'zone' entries in a message packet header were not correctly filled
  841.    (PackMail, MoveMail).
  842.  
  843. *  NetMgr wouldn't correctly detect a move/copy to the same area. That is
  844.    now properly catched.
  845.  
  846. *  Action Packmail and MoveMail can now have a packet password. Add this as
  847.    an extra parameter (optional), like this:
  848.  
  849.    Action PackMail 2:281/527.0 2:281/500.0 secret
  850.  
  851.    NetMgr will now use 'secret' as password for the packet for 281/500.
  852.  
  853. *  Debug mode would not correctly show the number of the mask that matched
  854.    (was always number 0).
  855.  
  856. *  Cosmetic change VIA lines (pointnumber will be stripped if 0).
  857.  
  858.  
  859. beta 1
  860. ------
  861.  
  862. *  Binkley mailpacking had mixed up 'truncate file when sent' and 'delete
  863.    file when sent' actions. The file would be truncated when it should be
  864.    deleted and v.v.
  865.  
  866. *  In mailpackets generated by NetMgr, the date generated would be
  867.    incorrect (NetMgr lived 80 years in the past :-).
  868.  
  869. *  NetMgr would accept '*' as origination address in several actions
  870.    (Packmail, MoveMail, Bounce actions, EchoCopy/Move). This is not
  871.    supported and can lead to problems. NetMgr will now check for this while
  872.    reading the config.
  873.  
  874. *  NetMgr would not recognize certain attributes (like 'file request') in
  875.    Hudson areas.
  876.  
  877. *  More than one EchoCopy action for the same mask would result in addition
  878.    of multiple tearline/origin combinations.
  879.  
  880. *  AddNote and Bounce will not add dashes ('--') and empty lines around
  881.    your text (that is added at the top of the message) anymore. If you want
  882.    it, add it to your own text. If you don't want it, you now finally got
  883.    rid of it :-)
  884.  
  885. *  New Action: Display <line to display>
  886.  
  887.    This one will display a line of text on the screen and in the logfile.
  888.    You can use this to add details about certain actions to the logfile.
  889.    Example:
  890.  
  891.    Mask *, *, Pietje Puk, *, *, *
  892.    Action Display Deleted message to Pietje Puk!
  893.    Action Delete
  894.  
  895.    Whenever this action is executed, the line 'Deleted message to Pietje
  896.    Puk!' will be shown on the screen and added to the logfile. Leading and
  897.    trailing spaces are not touched, the line is displayed exactly as found
  898.    in the config (The first space, between 'Display' and 'Deleted' in this
  899.    case, *does* of course get stripped..).
  900.  
  901.    Please note that some actions prevent NetMgr from looking for more
  902.    actions to perform. Delete is one of them: after a message is deleted,
  903.    there is nothing that can be done with that message anymore and NetMgr
  904.    stops scanning for more actions. (Echo-)move is another example.
  905.  
  906.    Of course, 'Display' is something that *can* be done even after a
  907.    message is deleted, it is an exception to this. But I have not changed
  908.    NetMgr logic yet, keep that in mind.
  909.  
  910.    So this:
  911.  
  912.    Mask *, *, Pietje Puk, *, *, *
  913.    Action Delete
  914.    Action Display Deleted message to Pietje Puk!
  915.  
  916.    Doesn't work, because NetMgr will never get to the 'Display' action.
  917.  
  918.  
  919.